https://www.youtube.com/watch?v=kuUQyv-rysw
1. 이건 꼭 알아야 한다[^1]
[? 질문] 데브옵스(DevOps)에서 말하는 “성과”는 무엇이며, 왜 인프라/배포 표준화가 그 성과를 좌우하는가[^2]
[= 답] 데브옵스의 목표는 시간 흐름과 인원 증가에도 **팀의 일의 속도(가속도)**가 떨어지지 않고 오히려 “곡선 위로 올라가게” 만드는 것이며, 이를 위해 안정적·신뢰 가능한 인프라와 자동화/측정/공유/축적이 전제되어야 한다.[^16]
[? 질문] 퍼블릭 클라우드(AWS)는 “쉽다”와 “어렵다”가 동시에 성립하는데, 그 이유는 무엇인가[^17]
[= 답] EC2, VPC, Route 53, ACM+ALB, Code 시리즈, CloudWatch 등으로 “구축 자체”는 쉬워졌지만, 수많은 서비스와 기능을 **모범 사례(Well-Architected, 멀티 어카운트/멀티 VPC 등)**로 “올바르게 조합·운영”하는 일은 훨씬 복잡해졌기 때문이다.[^20]
[? 질문] AWS Proton은 데브옵스 조직의 어떤 현실 문제(중앙관리 vs PaaS 종속 vs 자체 플랫폼 유지보수)를 어떻게 풀려는가[^22]
[= 답] 인프라/데브옵스가 만든 **표준 템플릿(환경/서비스)**을 기반으로 개발자가 셀프서비스·원클릭 배포를 하게 하면서, 표준·보안·컨벤션·관측성(모니터링)·파이프라인화를 템플릿에 녹여 중앙관리 장점을 가져오되, 템플릿/통합 확장(향후 Terraform 등)으로 유연성도 확보하려는 완전관리형 배포 서비스이다.[^33]
2. 큰 그림[^3]
이 발표는 데브옵스 엔지니어가 수행하는 업무의 본질(문화·자동화·측정·공유·축적)과, 서비스 규모/복잡도 증가로 인해 “아키텍처와 배포 표준화”가 왜 점점 더 어려워지는지를 짚은 뒤, 그 해법 중 하나로 AWS의 신규 서비스 AWS Proton을 개념·구성요소·사용흐름·로드맵 관점에서 설명한다.[^4]
- 데브옵스는 단순히 개발+운영의 결합이 아니라, 요구사항을 효율적으로 만족시키기 위해 자동화, 측정, 투명한 공유, 지속적 축적을 수행하는 문화/철학/방법론/기술이다.[^5]
- 클라우드는 구축을 쉽게 했지만, 현대 서비스(마이크로서비스, 폭발적 트래픽, 멀티계정 등)의 성장을 위해서는 모범 사례 기반의 표준화된 인프라/배포 체계가 필요해졌고, 이것이 팀 퍼포먼스 곡선을 좌우한다.[^18]
- AWS Proton은 인프라 관리자가 정의한 환경 템플릿 + 서비스 템플릿으로 개발자가 셀프서비스 배포를 하게 하며, 버전관리/파라미터/대시보드/CI/CD 연계로 표준 준수와 속도를 동시에 노린다.[^40]
3. 하나씩 살펴보기[^6]
3.1 발표자 소개와 “데브옵스 정의”를 먼저 꺼내는 이유[^7]
발표자는 행사에서 AWS 신규 서비스 중 “데브옵스 엔지니어를 위한 서비스”를 소개하기 전에, 먼저 데브옵스 업무와 방향성을 짚겠다고 한다.[^8] 이는 특정 제품 기능 나열이 아니라, “왜 이런 서비스가 필요해졌는가”를 이해시키려는 전개다.[^8]
발표자가 데브옵스를 설명할 때 항상 사용한다는 다섯 가지 키워드는 다음이다.[^9]
- 데브옵스는 문화다.[^9]
- 데브옵스는 자동화다.[^9]
- 데브옵스는 “항상 측정”한다.[^9]
- 측정한 것과 변경사항을 서로 투명하게 공유한다.[^9]
- 그 모든 결과와 학습을 축적해 나간다.[^9]
여기서 발표자는 “데브옵스 = 개발도 하고 운영도 하는 합성어” 정도로 단순화하는 관점을 부정한다.[^10] 데브옵스는 어떤 요구사항을 효율적으로 만족시키기 위해 일을 자동화하고, 변경사항/지표를 측정·공유하며, 결과를 지속적으로 축적해가는 문화이자 철학/방법론/기술이라고 정리한다.[^10]
[!IMPORTANT] 데브옵스를 “역할의 합”이 아니라 “성과를 내기 위한 운영체계”로 본다
발표자는 데브옵스의 핵심을 자동화·관측(측정)·공유·축적이 돌아가는 문화/체계로 놓고, 이후 AWS Proton을 “그 체계를 구현하기 쉬워지게 하는 도구”로 연결한다.[^10]
3.2 “모든 개념은 진화한다”: 클라우드도, 데브옵스도 바뀌었다[^11]
발표자는 “모든 개념은 시간이 지나면 발전하고 진화한다”고 말하며, 데브옵스도 예외가 아니라고 한다.[^12] 이 흐름을 설명하기 위해 클라우드의 변화를 예로 든다.[^12]
- 예전에는 클라우드를 “컴퓨팅 자원을 빌려주는 개념” 정도로 볼 수 있었지만, 이제는 그렇게 정의하기 어렵다.[^13]
- AWS를 단순히 “컴퓨팅 자원”이라고 부르기에는 기능이 너무 많고 다양해, 그런 표현은 지나치게 광범위하고 부정확해졌다는 것이다.[^14]
이 인식 전환이 중요한 이유는, 클라우드가 발전할수록 데브옵스 업무도 그만큼 다양한 분야로 확장되고 복잡해지기 때문이다.[^15]
3.3 데브옵스 엔지니어의 업무 범위: 인프라와 닮았지만 더 확장된 영역[^15]
발표자는 “데브옵스 엔지니어가 하는 일”이 보통의 인프라 엔지니어 업무와 비슷하며 “거의 같다고 해도 틀리진 않다”고 말한다.[^16] 다만 데브옵스는 그것을 조금 더 확장한 개념이라고 덧붙인다.[^16]
그가 열거하는 주요 업무 축은 다음과 같다.[^17]
- 서비스 개발과 배포를 신속·정확하게 만들기
- 이를 위해 도구를 적용하거나 직접 개발하는 활동을 포함한다.[^17]
- 문제를 빠르고 정확하게 감지하기
- 테스트와 모니터링(관측)이 해당된다.[^18]
- 장애 발생 시 최대한 빠르게 해결하고 전파하기
- 단순 복구뿐 아니라 공유/전파(커뮤니케이션)까지 포함한다.[^18]
- 서비스 최적화
- 성능/비용/구조적 최적화 같은 개선 활동을 뜻한다.[^18]
- 좋은 아키텍처(확장 가능, 보안적으로 안전) 만들기
- 이는 시스템 엔지니어링 영역이며, 확장성과 보안 모두 포함된다고 말한다.[^19]
- 원활한 의사소통을 가능하게 하는 체계/도구 운영
- 이를 위해 소프트웨어 도구를 적용/교육/운영/개발하는 업무도 포함될 수 있다고 설명한다.[^20]
발표자는 “정말 다양한 업무들이 있지만” 간단히 표현하면, 목표는 결국 팀의 속도를 가속도 곡선 위로 올리는 것이라고 그래프 비유로 이어간다.[^21]
3.4 데브옵스의 목표를 ‘가속도 곡선’으로 설명: 서비스 성공의 방정식[^21]
발표자는 데브옵스의 목표를 “서비스 성장, 투입 인원, 시간의 흐름”에 따라 팀의 속도를 가속도 선상으로 끌어올리는 것이라고 말한다.[^22] 즉 시간이 지나고 사람이 늘어도 일이 느려지는 게 아니라, 더 잘하고 더 빨리할 수 있어야 한다는 주장이다.[^23]
그는 “이렇게 해야만 하는 이유가 반드시” 있는데, 그것이 “서비스 성공의 방정식”이기 때문이라고 한다.[^24]
여기서 그가 말하는 성공 방정식의 핵심 논리는 다음 흐름이다.[^25]
- 좋은 아이디어를 갖고 실행하는 것도 중요하지만,[^25]
- 현대 서비스 성공의 키는 “좋은 아이디어가 있을 때 우리 팀/조직이 그 아이디어를 얼마나 빨리 구현하고 적용할 수 있느냐”에 달려 있다.[^26]
- 결국 지속적인 시도와 실패를 반복해 성공에 다다르려면, 팀 퍼포먼스를 이상적인 곡선 위로 올려야 한다.[^27]
이 논리에서 인프라가 중요한 이유가 자연스럽게 연결된다.[^28]
- 시간이 지나고 인원이 늘수록 더 빠르게 일하려면, 그 기반이 되는 인프라가 중요하다.[^28]
- 데이터베이스, 클라우드 등 기반을 “잘 만드는 것”이 중요하며,[^29]
- 인프라가 안정적이고 신뢰할 수 있어야 곡선 위로 올라갈 “기본 조건”이 된다는 것이다.[^29]
3.5 AWS는 “쉽다”: 구축은 쉬워졌고, 도구 체계도 풍부해졌다[^30]
발표자는 “AWS는 참 쉽고 간단하다”고 말하며, 퍼블릭 클라우드 성장 덕분에 서비스를 손쉽게 구축할 수 있게 되었다고 설명한다.[^31] 그는 여러 예를 빠르게 나열하며 “기본 인프라 구성 요소를 빠르게 갖출 수 있음”을 강조한다.[^32]
예시로 언급된 구성 흐름(발표의 나열 순서)은 다음과 같다.[^32]
- 컴퓨팅 인프라 구축(EC2 등) 가능[^32]
- VPC 구성 가능[^32]
- Route 53로 저렴한 DNS 서비스 이용, 도메인 구매까지 가능[^33]
- ACM + ALB로 손쉽게 HTTPS 로드밸런서 구축 가능[^34]
- CodeBuild / CodeDeploy / CodePipeline 등 Code 시리즈로 코드 관리부터 배포 파이프라인까지 구축 가능[^35]
- 이러한 서비스들을 CloudWatch로 모니터링 가능[^36]
즉 “서비스를 만들고 배포하고 모니터링하는 기본 도구 상자”가 이미 AWS에 다 있다는 메시지다.[^36]
3.6 AWS는 “어렵다”: 모범 사례로 ‘올바르게’ 쓰는 일이 더 어렵다[^37]
발표자는 관점을 바꾸면 “AWS는 정말 어렵다”고 즉시 전환한다.[^38] 클라우드가 하드웨어 제약은 극복했지만, 아키텍처적으로 극복해야 할 과제가 남았고, 그 과제를 해결하기 위해 AWS 서비스가 계속 늘고 기능이 고도화되면서 복잡해졌다는 설명이다.[^39]
그가 강조하는 핵심 대비는 이것이다.[^40]
- AWS로 “무언가 만드는 것”은 쉽다.[^40]
- 하지만 수많은 서비스/기능을 적합하게, 올바르게, 모범 사례로 사용하는 것은 매우 어렵다.[^41]
특히 다음과 같은 모범사례 아키텍처를 구성하려면 복잡하고 주의 깊게 생각할 부분이 너무 많다고 한다.[^42]
- 멀티 어카운트
- 멀티 VPC
- 기타 모범사례 아키텍처 전반[^42]
그리고 그는 “중요한 것은 무엇을 알고 있느냐가 아니라, 잘 알고 잘 사용할 수 있고 잘 적용할 수 있는 것”이라고 정리한다.[^43]
3.7 현대 아키텍처의 복잡성: 아마존닷컴 아키텍처 그림, IoT, 폭증 트래픽, 마이크로서비스 필수화[^44]
발표자는 많은 사람들이 봤을 법한 “아마존닷컴 서비스를 표현한 그림(복잡한 서비스 아키텍처 다이어그램)”을 언급하며, 기술 발전과 사용자 요구사항 증가로 서비스 아키텍처가 더 복잡해진다고 말한다.[^45]
그는 다음과 같은 변화 요인을 연결한다.[^46]
- IoT 시대 도래, 네트워크 속도 증가, 영상 등 콘텐츠 증가[^46]
- 사용자 수 폭증 → 서비스 아키텍처의 진화와 복잡도 증가[^47]
- 이제는 “하나의 복잡한 세상”처럼 되었다는 비유[^47]
그리고 폭발적 트래픽을 감당하기 위해 **마이크로서비스 아키텍처(MSA)**가 “선택이 아니라 필수”가 되어가고 있다고 말한다.[^48]
이때 그는 규모 차이를 직관적으로 대비한다.[^49]
- “1만 명이 쓰는 서비스”와 “1억 명이 쓰는 서비스”는 완전히 다른 이야기, 다른 세상이다.[^49]
3.8 이상적인 빨간 곡선 vs 현실: 전문인력 부족, 커뮤니케이션 문제, 갈등, 예기치 못한 장애[^50]
발표자는 다시 “JEFF라고 불리는 그래프(이상적인 빨간 곡선)”를 꺼내며, 모두가 이상을 목표로 하지만 대부분의 조직은 그렇지 못하다고 말한다.[^51]
그 이유로 드는 현실 제약은 다음과 같다.[^52]
- 전문 인력 부족이 가장 큰 문제[^52]
- 의사소통 문제, 사람 간 갈등 등 다양한 문제[^53]
- 서비스 특성에 따라 문제가 다르고, 예기치 못한 문제/극복 과제가 수도 없이 존재[^54]
3.9 실제 도전 과제 예시: “평소 대비 100배 트래픽”, 분당 100만/200만 vs 800만/900만의 질적 차이[^55]
발표자는 자신의 팀 사례로 “트래픽 패턴”을 제시한다.[^56] 평소 대비 100배 이상 트래픽이 들어오는 상황이 많은 도전과제를 만든다는 것이다.[^56]
그는 처리량을 예로 들며 “규모가 커지면 문제 성격이 달라진다”를 강조한다.[^57]
- 분당 100만 트래픽, 200만 트래픽을 해결해도[^57]
- 분당 800만, 900만 트래픽이 들어오는 것은 “정말 다른 이야기”다.[^58]
이런 상황을 극복하기 위해 선택지가 다양해지고(컨테이너, ECS, Fargate, 혹은 다른 선택지 등), 선택지마다 모범사례가 전부 다르기 때문에 인프라 자원을 어떻게 관리할지가 중요하다고 결론낸다.[^59]
3.10 인프라 자원 관리 방식 3가지: 중앙관리 vs PaaS vs 자체 플랫폼(중간지대)[^60]
발표자는 인프라 자원 관리 방법을 크게 3가지로 나눠 비교한다.[^61]
(1) 좌측: 표준화가 용이한 “중앙 관리” 방식[^62]
- 인프라를 관리하는 팀이 존재하며, 팀이 전적으로 생성·관리한다.[^62]
- 표준화와 모범사례 구축에 유리하다(인프라 엔지니어가 인프라를 만들기 때문).[^63]
- “그들이 제일 잘하는 일을 하니까”라는 표현으로 전문성 기반 장점을 강조한다.[^63]
하지만 단점/전제조건도 명확히 말한다.[^64]
- 인프라팀/데브옵스팀을 구성할 수 있는 규모가 필요[^64]
- 모범사례를 구축할 전문 인력이 반드시 필요[^65]
- 전문 인력 없이 누군가가 인프라를 만들면 “한 번 잘못된 것이 계속 전파되는 문제”가 생길 수 있다.[^66]
- 개발자는 티켓 오픈, 서비스 성격 설명 등 의사소통이 필요하고 문서화가 필요할 수도 있다.[^67]
- 결국 팀 전체가 “고도화된 소통 방식”을 갖춘 수준이어야 이 방식을 채택 가능하다고 한다.[^68]
(2) 우측: 구축이 쉽고 속도가 높은 “PaaS/플랫폼 서비스 사용”[^69]
- 접근이 쉽고 쓰기 쉽다.[^69]
- 인프라 수준 이해도가 높은 인력이 없다면 좋은 선택지일 수 있다.[^70]
단점은 “종속(lock-in)”이다.[^71]
- 원하는 방식으로 부연/확장을 못할 수 있고, 고도화가 플랫폼에 묶인다.[^71]
- 모범사례 구축이 어렵고, 서비스가 성장·진화할수록 다양한 요구사항을 충족하지 못할 수 있다.[^72]
- 그래서 대부분 처음에는 PaaS를 선택하다가, 성장에 따라 변화를 겪어야 하는 순간이 온다고 설명한다.[^73]
(3) 중간: “자체 솔루션/플랫폼 구축”[^74]
- 개발자들이 사용할 수 있는 플랫폼을 직접 만든다.[^74]
- 가장 큰 장점: 직접 개발하니 원하는 입맛/형태로, 가장 적합하게 만들 수 있다.[^75]
단점은 유지보수 리스크다.[^76]
- 모두 직접 개발하고 유지보수해야 하며,[^76]
- 여러 명이 유지하면 좋지만 1명이 유지하다가 이탈하면 변화가 커져 어려움이 생길 수 있다.[^77]
발표자는 “무엇을 선택할지는 자유”이며 팀/서비스 성격에 따라 검토 후 선택해야 한다고 정리한다.[^78]
3.11 이런 문제를 해소하려 AWS가 내놓은 신규 서비스: AWS Proton 소개[^79]
발표자는 앞의 관리방식 딜레마를 해소하기 위해 AWS가 신규 서비스를 출시하며, 오늘 소개할 서비스가 AWS Proton이라고 말한다.[^80]
그는 AWS re:Invent 2020에서 데브옵스 관련 서비스가 많이 출시됐고, 그중 Proton은 “누구나 쉽게 컨테이너와 서버리스 서비스를 손쉽게 배포”하게 해주는 서비스라고 설명한다.[^81] 또한 그 과정에서 인프라/데브옵스가 의도한 표준과 모범사례를 준수하게 해, 앞서 말한 “중앙관리식 장점”을 가질 수 있다고 한다.[^82]
특히 그가 Proton을 소개하는 이유는 다음 문장에 있다.[^83]
- Proton은 AWS가 “첫 번째로 출시한 컨테이너와 서버리스를 위한 완전 관리형 배포 서비스”라는 점.[^83]
- “첫 번째로 출시했다”는 의미가 중요 포인트라고 강조한다.[^84]
그는 지금까지 오픈소스/상용 배포 서비스가 많았고, 많은 사람들이 직접 배포 플랫폼을 만들어 써왔다는 배경을 깔면서,[^85] AWS가 “배포 서비스”를 공식적으로 내놓았다는 사실 자체가 AWS의 CI/CD 및 데브옵스 모범사례 철학을 엿볼 기회가 된다고 말한다.[^86]
즉 Proton을 꼭 쓰지 않더라도 다음을 학습할 수 있다는 주장이다.[^87]
- AWS가 생각하는 “배포(CI/CD)와 데브옵스 모범사례”가 무엇인지 유추 가능[^87]
- 복잡한 서비스를 경험한 AWS 엔지니어들이 생각하는 모범사례를 Proton을 통해 배우고, 철학과 기술을 학습할 수 있다.[^88]
3.12 AWS Proton의 기본 개념: 인프라 관리자(템플릿) ↔ 개발자(선택/배포) 사이의 중앙 허브[^89]
발표자는 Proton의 배포 개념을 “인프라 관리자와 개발자, 중앙에 Proton” 구조로 설명한다.[^90]
3.12.1 인프라 관리자의 역할: Infrastructure Template 정의/생성[^91]
인프라 관리자는 인프라스트럭처 템플릿을 정하고 생성한다.[^91] 이 템플릿을 통해 규칙을 만들고, 인프라/데브옵스가 생각하는 표준과 모범사례를 구현할 수 있다고 말한다.[^92]
템플릿 안에 들어갈 수 있는 예시는 다음처럼 언급된다.[^93]
- 규칙(컨벤션)
- 보안상 고려사항
- 기타 표준화 요소[^93]
3.12.2 개발자의 역할: 템플릿 선택 후 “그냥 배포”[^94]
개발자는 만들어진 템플릿을 보고 선택한 뒤 배포만 하면 된다는 것이 핵심이다.[^94] 발표자는 이를 “원클릭 형태로 배포”라고 표현한다.[^95]
개발자는 인프라 관리자가 만든 템플릿과 설명을 보고 적합한 애플리케이션 유형에 해당하는 템플릿을 선택해 배포를 올린다는 흐름이다.[^96]
3.12.3 배포는 반드시 ‘단계’와 ‘파이프라인’이어야 한다 + 모니터링 포함 + IaC 기반[^97]
발표자는 “리코(권고) 모범사례” 관점에서 배포는 단계별 과정이 존재하고 파이프라인화되어야 하며, 모니터링이 포함되어야 하고, 코드로서의 인프라(IaC) 사상 기반이어야 한다고 말한다.[^97] 인프라 관리자가 템플릿을 만들고 관리하는 이유가 바로 이것이라고 연결한다.[^98]
즉 Proton은 템플릿 자체에 IaC 성격과, CI/CD 파이프라인, 관측성(모니터링) 같은 기준을 “내장”시키려는 접근으로 설명된다.[^99]
3.13 Proton 핵심 기능 3가지(발표자의 요약): 셀프서비스, 중앙관리, 통합/업데이트 용이성[^100]
발표자는 Proton의 핵심 기능을 3가지로 요약한다.[^100]
- 누구나 쉽게 원클릭으로 셀프서비스 배포 가능해야 한다.[^101]
- 중앙관리 장점(표준화, 전문 인력이 의도한 사항이 누구에게나 적용)이어야 한다.[^102]
- 표준이 업데이트되면 바로/쉽게 적용 가능해야 하며, 오픈소스/다른 서비스와 통합도 되면 더 좋다.[^103]
3.14 Proton의 구성요소: “Environment(환경)”와 “Service(서비스)”[^104]
발표자는 Proton이 크게 **환경(Environment)**과 **서비스(Service)**로 이루어진다고 설명한다.[^104]
3.14.1 Environment(환경): 공유 기반 자원 정의[^105]
환경은 실제 서비스가 위치할 기본 공유 자원을 정의한 것이다.[^105] 예로 VPC와 클러스터를 든다.[^106]
그는 VPC/클러스터는 누가 만들고 어떻게 구성하느냐에 따라 “모양이 달라지고 개성을 가질 수” 있으며, 모범사례 또한 존재한다고 말한다.[^107] 즉 환경 템플릿이 중요한 이유가 “기반의 표준화/일관성”에 있다는 뉘앙스를 준다.[^107]
3.14.2 Service(서비스): 환경 위에서 돌아갈 컴퓨팅 + 코드[^108]
서비스는 환경 안에서 실제로 돌아갈 컴퓨팅 자원을 의미하며, 예로 ECS Fargate와 AWS Lambda를 든다.[^108] 또한 그 위에 올라가는 코드도 서비스에 포함된다고 설명한다.[^109]
3.15 마이크로서비스 예시 가정: Store Front / Inventory / Checkout + 다양한 AWS 연동 가능성[^110]
발표자는 더 구체적 설명을 위해 “ECS 마이크로서비스 아키텍처 기본 구성”을 가정한다.[^111] 예시로 3개 서비스를 설정한다.[^112]
- Store Front (웹 서비스)[^112]
- Inventory (서비스)[^112]
- Checkout (서비스)[^112]
그리고 실제로는 각 서비스가 데이터베이스/캐시/서드파티 연동 등 다양한 성격을 가질 수 있으며,[^113] 더 큰 규모라면 큐, 캐시, DynamoDB 등 다양한 AWS 서비스와 엮이고 서비스 가짓수도 늘어난다고 설명한다.[^114]
이 예시는 Proton이 “서비스 템플릿을 여러 개 만들어두고 개발자가 선택”하는 모델이 마이크로서비스 확장과 잘 맞음을 보여주려는 장치다.[^114]
3.16 인프라 관리자가 만드는 템플릿 2종: 환경 템플릿 + 서비스 템플릿[^115]
발표자는 Proton에서 인프라 관리자가 템플릿을 만드는 역할이며, 이것은 두 가지 템플릿을 만든다는 뜻이라고 말한다.[^116]
- Environment Template 정의[^116]
- Service Template 정의[^116]
그리고 환경 템플릿으로부터 실제 환경(VPC/클러스터 등)을 생성하는 일은 보통 인프라 관리자가 맡을 것 같다고 한다.[^117] 다만 인프라 관리자가 아니더라도 이해도가 높은 개발자가 해도 되고, 팀 성격/규모에 따라 결정하면 된다고 유연하게 말한다.[^118]
반면 개발자는 개발에 집중해야 하므로 “이미 만들어진 서비스 템플릿만 보고” 선택해 쉽게 생성할 수 있어야 한다고 강조한다.[^119]
이 생성 과정은 AWS 콘솔 같은 웹 UI로 가능하며, 앞으로 CI 솔루션과 통합, CLI/SDK 제공으로 원하는 형태의 자동화/개발도 가능해질 것이라고 전망한다.[^120]
3.17 IaC 템플릿의 ‘진짜 목적’: 모든 환경을 일치시키는 것(Dev/Stage/Test/Prod)[^121]
발표자는 템플릿 형태(IaC 지향)로 구성한 이후의 핵심을 “모든 환경을 일치시키기 위함”이라고 못박는다.[^122]
그가 말하는 목표는 다음과 같다.[^123]
- 전문가(인프라/데브옵스)가 의도한 환경과 모범사례를
- 개발환경부터 실제 서비스 환경까지
- 비용 효율적으로, 완벽히 일치시키고 보장하면
- 업무 퍼포먼스가 늘고, 가속도 곡선 위로 올라가기 위한 기초를 쌓을 수 있다.[^123]
3.18 장애/문제 추적 시나리오: 환경 일치가 “인프라 의심”을 제거한다[^124]
발표자는 가정 시나리오로 “무언가 문제가 발생”했을 때를 든다.[^124] 문제의 원인을 추적할 때 다음 가능성을 다 열어놓고 검토해야 한다고 말한다.[^125]
- 개발자 코드 문제인지[^125]
- 인프라 설정 문제인지[^125]
- 보안 사항 때문인지[^125]
- 방화벽 문제인지[^125]
- 기타 다양한 방면[^125]
프로덕션에서 문제가 생겼을 때도 동일하게 복잡하다는 것이다.[^126]
하지만 Dev/Stage/로드테스트/Prod까지 모든 환경을 의도대로 일치시킬 수 있다면, 최소한 “인프라에 대한 의심”은 완전히 없어질 수 있다고 주장한다.[^127] 그러면 개발자는 자신의 문제(코드)에 집중하고, 본연의 업무에 집중하면 퍼포먼스가 증가한다는 논리다.[^128]
인프라 관리자는 본연의 업무(서비스 안정성 향상)와 비즈니스에 효과적인 일을 선택해 할 수 있다고 덧붙인다.[^129]
[!TIP] 환경 일치의 효과를 “디버깅 범위 축소”로 설명
발표자는 환경 표준화가 단지 편의가 아니라, 장애 시 원인 후보군에서 인프라 변수를 제거해 개발/운영 모두의 시간을 단축한다고 본다.[^127]
3.19 파라미터/강제값: 하나의 템플릿으로 여러 환경·서비스를 만든다[^130]
발표자는 Proton이 다양한 환경을 지원해야 하므로, 파라미터와 특정 값 강제가 가능하다고 설명한다.[^130] 파라미터화란 하나의 템플릿에 값을 주입하여 여러 개 환경/서비스를 만들 수 있게 하는 방식이다.[^131]
즉 “동일한 템플릿으로 다양한 실제 환경이나 서비스를 만들 수 있다”는 뜻이다.[^132]
그가 든 예시는 Route 53 DNS다.[^133]
- DNS 생성 시 서브도메인만 바꾸면 dev/stage/prod 등을 구분할 수 있으니,
- 바뀌는 값(서브도메인)만 지정해서 하나의 템플릿으로 여러 환경/서비스를 만든다는 설명이다.[^133]
그는 DNS뿐 아니라 다음도 파라미터가 될 수 있다고 말한다.[^134]
- 컨테이너 개수
- CPU/메모리 사양[^134]
이런 것들은 계속 고도화/변수화될 수 있고, IaC처럼 인프라를 코드로 구성하는 것도 가능해진다는 기대를 덧붙인다.[^135]
3.20 콘솔로 템플릿 생성: 입력 화면이 많지 않다 + 네이밍 컨벤션/설명(디스크립션)의 중요성[^136]
발표자는 AWS 콘솔 화면을 통해 Proton 과정을 실행할 수 있다고 하며, 콘솔로 템플릿을 손쉽게 생성할 수 있고 실제 입력해야 하는 화면이 많지 않다고 말한다.[^136]
중요 포인트로 그는 “네이밍”을 든다.[^137]
- 네이밍을 짓는 게 어렵다.[^137]
- 하지만 Proton에서는 “이름 기반으로 신속하게 소통”할 수 있도록, 무엇을 어떻게 이름 지을지 고민하면 된다는 식으로 말한다.[^138]
또한 팀을 위한 템플릿 관점에서, 인프라 관리자는 만든 템플릿이 콘솔에서 한눈에 들어오게 관리되어야 한다고 한다.[^139]
그가 보여주는 예시 화면 설명에는 (샘플로) 여러 템플릿이 나열되어 있고, 디스크립션에 “이 서비스가 무엇인지/특성이 무엇인지/원하는 서비스가 무엇이면 이것을 선택하라” 같은 안내를 넣을 수 있다는 내용이 포함된다.[^140]
3.21 샘플 템플릿과 ‘오픈소스 특성’: 공유하고 참조·변형해 쓰는 모델[^141]
발표자는 Proton이 샘플 템플릿을 제공하며,[^141] 결국 “잘 만들어진(Well-Architected) 환경”을 구성할 수 있어야 한다고 말한다.[^142]
여기서 그는 Proton이 “오픈소스 특성”을 가져야 한다고 주장하며,[^143] 그 의미를 다음처럼 풀어낸다.[^144]
- 오픈소스처럼 구성된 Proton은 다양한 템플릿을 사용자에게 공유할 수 있다.[^144]
- 누군가가 잘 만든 템플릿을 공유하면, 우리는 이를 참조해 입맛대로 변경하여 사용할 수 있다.[^145]
그는 AWS가 공식 제공하는 Proton 샘플 템플릿이 있으며, 현재는 퍼블릭 프리뷰라 양이 많지 않다고 설명한다.[^146]
3.22 템플릿 버전관리: 메이저/마이너 분리, “투명한 업데이트”와 “선택적 업데이트”[^147]
발표자는 VPC/클러스터 구성 같은 환경 템플릿은 변경이 일어날 수 있으니, 템플릿 버전관리가 지원되어야 한다고 말한다.[^147]
그리고 Proton의 고도화된 부분으로 “메이저 버전”과 “마이너 버전” 관리를 분리할 수 있다고 설명한다.[^148]
- 마이너 버전: 완전히 투명한 업데이트가 가능. 업데이트가 일어나도 사용하는 개발자/엔지니어가 “버전업이 일어났는지 모를 정도로” 투명하게 진행될 수 있다는 뜻이다.[^149]
- 메이저 버전: 사용자에게 선택지를 주는 업데이트. 변경사항이 진행됐으니 최신 버전을 쓰거나 버전업이 필요하다는 것을 공지/유도할 수 있다.[^150]
이 파트는 “중앙표준을 개선하면서도, 사용자 영향도를 통제하는 방식”을 설명하는 대목이다.[^150]
3.23 개발자 관점의 서비스 템플릿 선택: 깊은 인프라 이해 대신 런타임 특성 이해로 전환[^151]
발표자는 개발자가 “어떤 서비스 템플릿을 선택할 수 있어야 한다”는 점이 굉장히 중요하다고 말한다.[^151] 개발자가 다양한 템플릿 중 지정/생성만 할 수 있다면 퍼포먼스가 성장한다는 논리다.[^152]
현재 예시에서는 Fargate 웹 서비스, Lambda 서비스 정도로 한정돼 보이지만,[^153] Proton이 성장하면 더 다양한 서비스 템플릿이 나오고, 심지어 ECS 형태를 폭넓게 지원할 수도 있다고 전망한다.[^154]
여기서 그는 개발자에게 요구되는 역량의 방향을 다음처럼 제시한다.[^155]
- 개발자는 인프라를 “굉장히 깊게” 이해하는 것이 아니라,[^155]
- Fargate 특성, Lambda 특성, ECS 특성 등 “서비스 특성”만 이해하고,[^156]
- 그에 맞는 서비스 템플릿을 “선택”하면 된다는 모델이다.[^156]
3.24 템플릿이 문서/교육자료가 된다: 인프라 관리자의 명세/공유 → 개발자의 학습/선택 가속[^157]
발표자는 프로세스를 다음처럼 그린다.[^157]
- 인프라 엔지니어(관리자)가 다양한 템플릿을 만들고, 템플릿 명세서/도큐먼트를 만든다.[^157]
- 템플릿이 어떤 특성을 갖고, 무엇을 고려해 만들어졌는지 공유한다.[^158]
- 개발자는 이를 보고 템플릿을 선택한다.[^158]
그는 “템플릿이기 때문에 항상 비슷한 형태의 교육자료가 된다”고 말하며, 개발자 성장에도 도움이 되고 무엇을 통해 서비스를 만들어야 할지 손쉽게 알 수 있다고 주장한다.[^159]
또한 개발자가 콘솔에서 특정 서비스(Fargate/Lambda 등)를 눌러 “어떤 서비스 템플릿을 이용하고 있는지” 확인하는 방식으로, 템플릿을 쉽게 선택해 배포할 수 있다고 한다.[^160]
3.25 파라미터 입력과 ‘표준화’: 필수/선택 옵션을 템플릿에서 설계한다[^161]
발표자는 템플릿 선택 후에는 파라미터 입력이 가능해야 한다고 말한다.[^161] 예로 캐시 크기, Route 53 주소 같은 값들을 든다.[^162]
여기서 강조는 다시 “표준화”다.[^163]
- 템플릿을 만드는 인프라 관리자 입장에서는 “무엇을 입력할지에 대한 선택지”를 주면 된다.[^163]
- 어떤 선택지는 반드시 입력해야 하는 필수값이 될 수 있고,[^164]
- 어떤 것은 **옵션(선택)**일 수 있다.[^164]
그는 현재는 웹 콘솔 중심이지만, 향후 고도화되면 코드로 배포하는 형태로 발전할 것이라고 본다.[^165] 그러면 개발자는 익숙한 방식으로 파라미터만 입력해 원하는 인프라를 만들고 빠르게 배포할 수 있다는 설명이다.[^166]
또한 서비스 배포를 위해 Dockerfile 선택, 브랜치 선택 같은 옵션도 있으며, 개발자는 코드에 집중하면 된다고 말한다.[^167]
3.26 서비스 관리/대시보드/상태: 배포 성공·실패·진행, 시점까지 한눈에[^168]
발표자는 서비스 관리 측면에서 “배포된 서비스가 잘 떴는지, 어떤 템플릿으로 떴는지”를 한눈에 볼 수 있어야 하며, 일종의 대시보드 역할이 필요하다고 말한다.[^168]
현재도 간략한 대시보드 형태 화면이 이미 있고,[^169] 앞으로 CloudWatch가 붙거나 더 고도화될 것이라고 전망한다.[^169]
그는 대시보드에서 다음을 알 수 있으면 편의성이 크다고 말한다.[^170]
- 배포 상태(status): 실패/진행 중/성공[^170]
- 성공했다면 “언제 성공했는지”까지 정확히 확인[^170]
그리고 서비스 모니터링(헬스 모니터링)이 가능해야 한다고 하며,[^171] 선택해 올린 서비스가 잘 되었는지, 안 되었다면 어느 부분에서 문제가 생겼는지, 과정 중 몇 개가 어떤 상태인지 등을 기본 제공한다고 설명한다.[^172]
다만 AWS가 제공한 화면이 각 팀의 모범사례와 완전히 일치하진 않을 수 있지만, “기본적인 대시보드 형태를 구성해야 한다는 개념” 자체는 모범사례로 부를 수 있다고 말한다.[^173]
3.27 (당시) 퍼블릭 프리뷰 기준 Proton이 제공하는 것: CloudFormation 템플릿 + 배포 + CodePipeline 연계 CI/CD + 업그레이드[^174]
발표 시점에서 Proton은 출시한 지 얼마 안 된 퍼블릭 프리뷰 상태라고 밝힌다.[^174]
그 기준으로 제공 기능을 구체적으로 열거한다.[^175]
- CloudFormation 기반 템플릿 작성을 제공[^175]
- 템플릿 기반 서비스/환경 배포 제공[^175]
- AWS CodePipeline 연계 CI/CD 제공[^176]
- 템플릿 업그레이드(메이저/마이너) 및 그에 따른 서비스 배포 제공[^176]
3.28 Proton 로드맵: 헬스모니터링 고도화, CloudWatch 통합→Lambda 액션, Terraform 연계, 자동 태깅, 멀티어카운트, 템플릿 접근제어[^177]
발표자는 Proton이 이미 로드맵을 공개했다고 하며, 앞으로의 발전 방향을 항목으로 설명한다.[^177]
3.28.1 헬스 모니터링 고도화 + CloudWatch 통합[^178]
그는 앞서 말했듯 CloudWatch 통합이 진행될 것이라고 보고,[^178] CloudWatch가 통합된다는 것은 뒤에 Lambda Action(람다)을 붙일 수 있다는 뜻이라고 설명한다.[^179] 즉 배포 프로세스 뒤에 원하는 코드 실행을 추가할 수 있는 형태가 될 것이라는 전망이다.[^179]
3.28.2 다른 서비스와 통합 및 지원: Terraform 연계 계획 언급[^180]
공식 발표(re:Invent)에서 사람들이 많이 쓰는 Terraform 같은 것의 연계를 계획하고 있다고 말한다.[^180] 또한 사용자가 템플릿을 더 가공해 만든 것도 지원할 예정이라고 덧붙인다.[^181]
3.28.3 템플릿 레벨 자동 태깅[^182]
템플릿 레벨에서 자원에 대한 자동 태깅을 제공한다고 한다.[^182] 값 하나만 주면 템플릿으로 생성된 자원들에 필요한 태그를 일괄 부여하는 식의 표준화가 가능해진다는 설명이다.[^183] 이는 네이밍/태깅 규칙을 맞추는 데 도움이 된다는 맥락으로 연결된다.[^183]
3.28.4 멀티 어카운트 지원[^184]
그는 AWS 모범사례로 만들려면 멀티 어카운트는 “반드시 사용해야 한다”고 강조한다.[^184] 개발 환경과 프로덕션 AWS 계정을 분리하는 것은 이제 당연한 이야기라는 것이다.[^185] Proton도 Organizations 같은 서비스와 연계되거나 다른 방식으로든 멀티 어카운트를 지원할 것이라고 말한다.[^186]
3.28.5 템플릿 접근제어(IAM 통합)[^187]
큰 규모 조직에서는 개발팀이 많고, 팀마다 접근 가능한 템플릿이 다를 수 있으니 템플릿 접근제어가 필요하다고 한다.[^187] Proton이 AWS IAM과 통합해 이런 기능을 제공할 것이라고 전망한다.[^188]
3.28.6 지속적 업데이트: 고객 피드백 기반의 모범사례 진화[^189]
그는 모범사례 형태로 지속적으로 업데이트가 이루어질 것이고, 고객 피드백을 받을 것이라고 말한다.[^189]
3.29 Proton의 비전/방향: 신속·신뢰 가능한 컨테이너/서버리스 배포 모범사례 적용, 현대적(클라우드 기반) 아키텍처를 쉽게[^190]
발표자는 Proton의 방향/비전을 요약해 말한다.[^190]
- 고객이 신속하고 신뢰할 수 있는 컨테이너/서버리스 배포에 모범사례를 쉽게 적용하게 하는 것[^190]
- 클라우드 기반의 현대적 아키텍처(예: 마이크로서비스)를 쉽게 만들게 하는 것[^191]
- 인프라 팀이 비즈니스 성공을 위한 아키텍처를 만드는 데 집중할 수 있게 하는 것[^192]
그는 마이크로서비스를 만드는 것이 사실 쉬운 문제가 아니라고 덧붙이며,[^193] Proton이 그 진입장벽을 낮추는 의미가 있다고 본다.[^193]
3.30 Proton이 팀에 주는 기대효과(발표자의 논리): IaC 실천→작성/공유, CI 연계, 커뮤니케이션 비용 감소, 인프라팀의 역할 확장[^194]
발표자는 좀 더 자세히 풀어 다음을 말한다.[^194]
- 코드로서의 인프라(IaC) 사상을 완벽히 실천하면 모범사례를 빠르게 만들고 작성하고 공유할 수 있다.[^194]
- 코드 저장소(레포지토리)와 연계, CI와 연계할 수 있다.[^195]
- 컨테이너/서버리스를 접목해 마이크로서비스를 손쉽게 만들 수 있다.[^196]
또한 “인프라 템플릿 구축과 실제 생성”을 개발팀이 일부 수행하게 되면, 의사소통 비율을 줄이고 인프라팀 자체 업무를 줄여 인프라팀이 다른 일을 할 수 있다는 시나리오를 제시한다.[^197]
3.31 다시 ‘가속도 곡선’으로 돌아와서: Proton을 쓰거나, Proton을 기준으로 우리 수준을 점검하라[^198]
발표자는 다시 가속도 곡선을 언급하며 질문을 던진다.[^198]
[? 질문] 여러분의 서비스 팀은 어느 그래프 위에 있나요[^198]
[= 답] 발전을 기대하며 Proton 사용을 고려해볼 수 있고, 동시에 Proton의 배포 과정을 기준으로 현재 조직이 AWS가 말하는 철학/기술/모범사례 대비 어느 위치인지 비교·검토하는 기회로 삼을 수 있다.[^199]
그는 이 과정을 통해 “빨간색 그래프(이상적인 곡선)에 더 다가갈 수 있다”고 말한다.[^200]
3.32 인프라팀→데브옵스팀의 “진화”: 인프라 안정성뿐 아니라 조직 전체 퍼포먼스에 영향 주는 모든 일까지[^201]
발표자는 인프라팀이 기존 인프라 업무만 하던 형태에서 데브옵스팀으로 진화해야 한다면, “신뢰성 있는 인프라를 구축”하는 것 외에도 업무 퍼포먼스에 영향을 끼치는 모든 일을 할 수 있어야 한다고 주장한다.[^201]
그는 예시로 기획, 마케팅, 서비스 운영 인력이 겪는 문제들에도 자동화할 영역이 있을 수 있다고 말한다.[^202] 개발자에게는 코드 작성/스크립팅/CI 연계가 상대적으로 쉬울 수 있지만, 비전공자 또는 개발이 주업이 아닌 인력에게는 그것이 쉽지 않을 수 있다고 한다.[^203]
따라서 데브옵스팀이 이를 표준화하고, 마케팅팀/운영팀 업무를 자동화해 더 디지털한 업무 형태로 바꿀 수 있다면, 그것이 사람들이 말하는 디지털 트랜스포메이션을 이루는 것이라고 연결한다.[^204]
마지막으로 그는 “반드시 아키텍처를 고민하고, 팀과 팀의 수준을 고민해, 퍼포먼스와 일의 속도를 가속도 선상에 올리는 것이 가장 중요하다”고 정리하며 발표를 마친다.[^205]
4. 핵심 통찰[^206]
- 데브옵스의 정의를 “역할”이 아니라 **문화(자동화·측정·공유·축적)**로 잡는 순간, 배포/인프라 도구 선택은 ‘취향’이 아니라 ‘팀 성과 구조’가 된다.[^9]
- 클라우드는 구축을 쉽게 했지만, 성장한 서비스의 성공은 “올바른 조합(모범사례)”에 달려 있어, 복잡도가 필연적으로 증가한다.[^41]
- 트래픽이 100배가 되는 순간, 같은 해결책이 같은 방식으로 확장되지 않으며, 선택지(컨테이너/ECS/Fargate 등)마다 모범사례가 달라 표준화된 운영체계가 필요해진다.[^58]
- 인프라 관리의 3가지 방식(중앙관리·PaaS·자체 플랫폼)은 각각 장점이 있으나, 현실에서는 “표준화(중앙관리 장점)”와 “속도/쉬움(PaaS 장점)” 사이에서 균형이 필요하다.[^61]
- Proton의 핵심 가치는 “개발자가 인프라를 몰라도 된다”가 아니라, 개발자가 템플릿 선택/파라미터 입력에 집중하게 만들어 배포 속도를 올리고, 인프라팀은 표준/보안/관측성을 템플릿으로 강제하는 데 있다.[^94]
- “환경 일치(Dev/Stage/Test/Prod)”는 운영 편의가 아니라, 장애 분석에서 “인프라 변수를 제거”해 디버깅 비용을 줄이는 전략으로 제시된다.[^127]
- 템플릿 버전의 메이저/마이너 분리는 “중앙 표준의 지속 개선”과 “현업 영향 통제”를 동시에 달성하기 위한 운영 메커니즘으로 강조된다.[^149]
- 데브옵스팀의 확장은 개발조직 내부를 넘어 마케팅/운영 등 비개발 조직의 자동화까지 포함하며, 이를 디지털 트랜스포메이션과 연결한다.[^204]
- 실행 관점 시사점(발표 맥락 기반)
- 인프라팀이 표준/보안/네이밍/태깅/관측성을 **템플릿(정책화된 IaC)**로 먼저 정의할 것[^92]
- 개발자에게는 “서비스 특성 이해 → 템플릿 선택”의 학습 루트를 제공할 것[^156]
- Dev/Stage/Prod 환경 일치 수준을 점검하고, 불일치가 장애 분석 시간을 얼마나 늘리는지 측정해볼 것[^127]
- Proton을 도입하지 않더라도, Proton이 전제하는 파이프라인/모니터링/IaC/버전관리 관점을 기준으로 현재 배포 체계를 비교 점검할 것[^199]
5. 헷갈리는 용어 정리[^207]
데브옵스(DevOps): 개발과 운영의 단순 결합이 아니라, 요구사항을 효율적으로 만족시키기 위해 자동화하고 변경/지표를 측정·공유하며 결과를 축적해 나가는 문화/철학/방법론/기술.[^10]
모범사례(Best Practices / Well-Architected): 수많은 AWS 서비스/기능을 “적합하고 올바르게” 조합해 사용하는 방식으로, 멀티 어카운트/멀티 VPC 같은 아키텍처 패턴을 포함해 주의 깊은 설계가 필요하다고 설명됨.[^42]
IaC(Infrastructure as Code, 코드로서의 인프라): 인프라를 템플릿/코드로 정의하고 파이프라인·모니터링과 함께 관리해야 한다는 사상. Proton에서 인프라 관리자가 템플릿을 만드는 이유로 제시됨.[^97]
AWS Proton: 컨테이너/서버리스 배포를 위한 AWS의 완전관리형 서비스로, 환경/서비스 템플릿을 통해 표준 준수, 셀프서비스 배포, 버전관리, CI/CD 연계를 제공(발표 시점 퍼블릭 프리뷰).[^83]
Environment(환경): VPC, 클러스터 등 서비스가 올라갈 공유 기반 자원을 정의한 Proton의 구성요소.[^105]
Service(서비스): 환경 위에서 돌아갈 컴퓨팅(Fargate/Lambda 등)과 코드까지 포함하는 Proton의 구성요소.[^108]
메이저/마이너 버전(템플릿 버전관리): 마이너는 사용자에게 투명한 업데이트, 메이저는 선택지를 주는 업데이트로 설명됨.[^149]
멀티 어카운트(Multi-account): 개발/프로덕션 등 환경을 계정으로 분리하는 AWS 모범사례로 “이제 당연한 이야기”라고 언급됨.[^185]
참고(콘텐츠 정보)[^208]
- 제목: 데브옵스 엔지니어를 위한 AWS 신규 서비스 소개 - 송주영 데브옵스 엔지니어, beNX[^208]
- 출처/채널: Amazon Web Services Korea[^208]
- 길이: 42분 25초[^208]
- 링크: https://www.youtube.com/watch?v=kuUQyv-rysw[^208]
[^1]: @[00:00]~ 발표 시작 인사 및 전체 흐름 도입.
[^2]: @[00:35] 데브옵스 정의(문화/자동화/측정/공유/축적)와 @[03:39] 목표 그래프(가속도) 언급.
[^3]: @[00:14] 서비스 소개 전 데브옵스 업무/방향성 설명 예고.
[^4]: @[00:14]~@[01:13] 데브옵스 개념 설명 → @[13:10] Proton 소개로 연결.
[^5]: @[00:35] “문화…자동화…측정…투명하게 공유…축적” 및 @[00:51] 부연 설명.
[^6]: @[00:14] “본격적인 서비스 소개 전에…” 이후 순차 전개 전체.
[^7]: @[00:02]~@[00:06] 발표자(컨테이너 히어로 송주영) 소개.
[^8]: @[00:14]~@[00:19] 서비스 소개 전에 업무/방향성부터 보겠다는 선언.
[^9]: @[00:35] 데브옵스를 다섯 단어로 정의.
[^10]: @[00:51]~@[01:13] 단순 합성어가 아니라 요구사항 효율 충족을 위한 자동화/측정/공유/축적 문화라는 설명.
[^11]: @[01:17] 개념의 진화 언급.
[^12]: @[01:17]~@[01:24] 데브옵스도 계속 진화.
[^13]: @[01:29]~@[01:35] 클라우드가 단순 컴퓨팅 자원 대여 개념이었던 과거.
[^14]: @[01:41]~@[01:52] AWS를 단순 컴퓨팅 자원이라 부르기엔 기능이 너무 많음.
[^15]: @[01:58]~@[02:16] 데브옵스 업무가 다양하고 여러 분야에 걸쳐 있음.
[^16]: @[02:22]~@[02:35] 데브옵스 업무는 인프라 엔지니어와 유사하나 확장된 개념.
[^17]: @[02:35]~@[02:45] 배포 신속/정확화를 위한 도구 적용/개발.
[^18]: @[02:45]~@[02:59] 문제 감지(테스트/모니터링), 장애 해결/전파, 최적화.
[^19]: @[03:00] 확장 가능/보안적으로 안전한 아키텍처 포함.
[^20]: @[03:12]~@[03:18] 의사소통을 가능하게 하는 도구 적용/교육/운영/개발 포함.
[^21]: @[03:30]~@[03:54] 그래프로 표현: 목표는 속도를 가속도 곡선 위로.
[^22]: @[03:39]~@[03:51] 시간/인원 증가에 따라 팀 속도를 가속도 선상으로 올린다는 설명.
[^23]: @[04:33]~@[04:38] 시간이 지날수록/사람이 많아질수록 더 잘·빠르게 해야 함.
[^24]: @[03:58]~@[04:02] “서비스 성공의 방정식”.
[^25]: @[04:02]~@[04:12] 좋은 아이디어와 실행의 중요성 언급.
[^26]: @[04:12]~@[04:18] 아이디어를 얼마나 빨리 구현/적용하느냐가 현대 서비스 성공의 키.
[^27]: @[04:25]~@[04:33] 지속적 시도/실패 반복을 통한 성공, 그래프 위로 올려야.
[^28]: @[04:48] 기반 인프라의 중요성 연결.
[^29]: @[04:52]~@[04:59] 인프라 안정/신뢰가 곡선 위로 올라갈 기본 조건.
[^30]: @[05:04] “AWS는 참 쉽고 간단합니다” 시작.
[^31]: @[05:06]~@[05:12] 퍼블릭 클라우드 성장으로 손쉽게 서비스 구축.
[^32]: @[05:16]~@[05:26] VPC/컴퓨팅/Route53 등 언급.
[^33]: @[05:26]~@[05:30] Route53로 도메인 구입까지 가능.
[^34]: @[05:30]~@[05:36] ACM+ALB로 HTTPS 로드밸런서 구축.
[^35]: @[05:38]~@[05:50] CodeBuild/Deploy/Pipeline로 코드 관리~파이프라인 구축.
[^36]: @[05:50]~@[05:56] CloudWatch로 모니터링.
[^37]: @[05:58] 관점 전환 예고.
[^38]: @[06:01]~@[06:06] “AWS는 정말로 어렵습니다.”
[^39]: @[06:06]~@[06:29] 서비스/기능 고도화로 복잡/어려움.
[^40]: @[06:29]~@[06:34] 만드는 건 쉽지만…
[^41]: @[06:34]~@[06:39] 올바르게/모범사례로 사용하는 건 매우 어려움.
[^42]: @[06:44]~@[06:57] 멀티 어카운트/멀티 VPC 등 모범사례 구성의 복잡성.
[^43]: @[06:57]~@[07:14] 아는 것보다 잘 사용/적용이 중요.
[^44]: @[07:14] 아키텍처 그림 소개.
[^45]: @[07:19]~@[07:23] 아마존닷컴 서비스 그림.
[^46]: @[07:32]~@[07:38] IoT/네트워크 속도/영상 증가.
[^47]: @[07:38]~@[07:51] 사용량 폭증→아키텍처 복잡, “복잡한 세상” 비유.
[^48]: @[07:51]~@[08:00] 폭발적 트래픽 감당 위해 MSA는 필수.
[^49]: @[08:00]~@[08:09] 1만 vs 1억 사용자는 다른 세상.
[^50]: @[08:09]~ 이상적 그래프 재언급.
[^51]: @[08:13]~@[08:23] 이상적 빨간 곡선 vs 현실.
[^52]: @[08:25]~@[08:29] 전문 인력 부족.
[^53]: @[08:29]~@[08:35] 의사소통 문제/갈등.
[^54]: @[08:35]~@[08:47] 서비스 특성별 문제, 예기치 못한 문제와 극복 과제.
[^55]: @[08:47] 팀 사례 도입.
[^56]: @[08:52]~@[08:58] 평소 대비 100배 트래픽.
[^57]: @[09:05]~@[09:11] 분당 100만/200만 트래픽 해결 예.
[^58]: @[09:11]~@[09:16] 분당 800만/900만은 다른 이야기.
[^59]: @[09:17]~@[09:41] 컨테이너/ECS/Fargate 등 선택지와 모범사례 차이→자원 관리 중요.
[^60]: @[09:41] 인프라 관리 방식 소개.
[^61]: @[09:41]~@[09:49] 세 가지로 나눔.
[^62]: @[09:49]~@[10:01] 중앙 관리 방식 설명.
[^63]: @[10:01]~@[10:13] 표준화/모범사례 구축 용이, 전문성이 장점.
[^64]: @[10:17]~@[10:25] 팀 규모 필요.
[^65]: @[10:25]~@[10:32] 전문 인력 필요.
[^66]: @[10:32]~@[10:37] 잘못된 것이 지속 전파될 수 있음.
[^67]: @[10:43]~@[10:52] 티켓/설명/의사소통/문서화 필요.
[^68]: @[10:52]~@[11:03] 고도화된 소통 방식 필요, 팀 수준 전제.
[^69]: @[11:10]~@[11:22] PaaS/플랫폼 서비스 장점.
[^70]: @[11:22]~@[11:31] 인프라 이해 인력 없을 때 좋은 선택지.
[^71]: @[11:31]~@[11:43] 종속/확장 제한/고도화가 묶임.
[^72]: @[11:43]~@[11:49] 성장·진화할수록 요구사항 충족 어려울 수.
[^73]: @[11:55]~@[12:06] 처음 PaaS 선택 후 변화 시점 도래.
[^74]: @[12:06]~@[12:15] 자체 플랫폼(중간) 소개.
[^75]: @[12:19]~@[12:31] 원하는 입맛/형태로 최적화 가능.
[^76]: @[12:31]~@[12:37] 직접 개발/유지보수 부담.
[^77]: @[12:39]~@[12:56] 1인 유지보수/인력이탈 리스크.
[^78]: @[12:56]~@[13:07] 팀/서비스 성격에 따라 선택.
[^79]: @[13:10] 신규 서비스 출시로 문제 해소.
[^80]: @[13:15]~@[13:24] AWS Proton 소개.
[^81]: @[13:24]~@[13:38] 누구나 컨테이너/서버리스 손쉽게 배포.
[^82]: @[13:38]~@[13:46] 표준/모범사례 준수, 중앙관리 장점.
[^83]: @[13:58]~@[14:08] “첫 번째…완전 관리형 배포 서비스” 강조.
[^84]: @[14:08]~@[14:16] 첫 번째 출시 의미가 중요 포인트.
[^85]: @[14:16]~@[14:25] 오픈소스/상용 배포 서비스, 직접 개발 사례.
[^86]: @[14:34]~@[14:47] Proton 통해 AWS의 배포/CI/CD 데브옵스 생각을 알 수.
[^87]: @[14:34]~@[14:39] Proton을 쓰지 않아도 철학/모범사례 유추 가능.
[^88]: @[14:49]~@[14:55] AWS 엔지니어들이 생각하는 모범사례를 배우는 기회.
[^89]: @[15:05] 본격 개념 설명 시작.
[^90]: @[15:17]~@[15:23] 인프라 관리자/개발자/중앙 Proton 구조.
[^91]: @[15:23]~@[15:29] 인프라 관리자의 템플릿 정의/생성.
[^92]: @[15:29]~@[15:37] 표준/모범사례를 템플릿으로 구현.
[^93]: @[15:37]~@[15:43] 컨벤션/보안 고려사항 등 템플릿 포함 가능.
[^94]: @[15:47]~@[15:53] 개발자는 템플릿 선택 후 배포만.
[^95]: @[16:00]~@[16:07] 원클릭 형태 배포.
[^96]: @[15:55]~@[16:00] 적합한 템플릿 선택/배포.
[^97]: @[16:17]~@[16:36] 배포는 단계/파이프라인/모니터링 포함, IaC 기반.
[^98]: @[16:36]~@[16:43] 인프라 관리자가 템플릿 관리하는 이유.
[^99]: @[16:43]~@[16:54] IaC+CI/CD+관측성 내장 필요 언급.
[^100]: @[16:54]~@[16:59] 핵심 기능 3가지로 요약.
[^101]: @[17:01]~@[17:08] 원클릭/셀프서비스 배포.
[^102]: @[17:11]~@[17:24] 중앙관리 장점, 표준화, 의도 적용.
[^103]: @[17:24]~@[17:36] 업데이트 즉시 적용, 다른 서비스/오픈소스 통합 희망.
[^104]: @[17:53]~@[17:59] 환경과 서비스로 구성.
[^105]: @[17:59]~@[18:06] 환경=기본 공유 자원 정의.
[^106]: @[18:09]~@[18:13] 예: VPC, 클러스터.
[^107]: @[18:13]~@[18:24] 구성 방식에 따라 모양/개성, 모범사례 존재.
[^108]: @[18:25]~@[18:37] 서비스=컴퓨팅 자원(Fargate/Lambda).
[^109]: @[18:37]~@[18:44] 위에 돌아가는 코드도 의미.
[^110]: @[18:44] 가정 도입.
[^111]: @[18:47]~@[18:54] ECS 마이크로서비스 기본 구성 가정.
[^112]: @[19:00]~@[19:09] Store Front/Inventory/Checkout 예시.
[^113]: @[19:09]~@[19:19] DB/캐시/서드파티 연동 등 다양성.
[^114]: @[19:20]~@[19:36] 큐/캐시/DynamoDB 등 AWS 연동과 가짓수 증가.
[^115]: @[19:39] 템플릿 역할 재강조.
[^116]: @[19:43]~@[20:02] 환경 템플릿+서비스 템플릿 정의.
[^117]: @[20:02]~@[20:13] 환경 템플릿으로 생성된 VPC/클러스터는 보통 인프라 담당.
[^118]: @[20:13]~@[20:25] 이해도 높은 개발자가 해도 되고 팀 특성 따라 결정.
[^119]: @[20:25]~@[20:46] 개발자는 서비스 템플릿만 보고 쉽게 생성해야.
[^120]: @[20:46]~@[21:05] 콘솔 UI, 향후 CI 통합, CLI/SDK 제공 전망.
[^121]: @[21:12] 템플릿 구성의 목적 설명 시작.
[^122]: @[21:12]~@[21:19] 핵심은 모든 환경 일치.
[^123]: @[21:19]~@[21:45] 의도한 환경/모범사례를 dev~prod까지 일치/보장→퍼포먼스 향상.
[^124]: @[21:51]~@[21:55] 문제 발생 가정.
[^125]: @[22:01]~@[22:13] 코드/인프라 설정/보안/방화벽 등 다각 검토.
[^126]: @[22:15]~@[22:19] 프로덕션 문제도 동일.
[^127]: @[22:19]~@[22:34] 모든 환경 일치 시 인프라 의심 제거.
[^128]: @[22:38]~@[22:50] 개발자는 개발에 집중→퍼포먼스 증가.
[^129]: @[22:54]~@[23:05] 인프라 관리자는 안정성 향상/비즈니스 효과적 일에 집중.
[^130]: @[23:05]~@[23:14] 파라미터/특정 값 강제 가능.
[^131]: @[23:14]~@[23:27] 파라미터 주입으로 여러 환경/서비스 생성.
[^132]: @[23:28]~@[23:33] 동일 템플릿으로 다양한 환경/서비스.
[^133]: @[23:35]~@[24:00] Route53 서브도메인 예시로 환경 구분.
[^134]: @[24:02]~@[24:12] 컨테이너 수, CPU/메모리 등도 파라미터.
[^135]: @[24:12]~@[24:26] 고도화/변수화, IaC처럼 구성 가능.
[^136]: @[24:26]~@[24:43] 콘솔로 템플릿 생성, 입력 화면 많지 않음.
[^137]: @[24:59]~@[25:08] 네이밍의 어려움 언급.
[^138]: @[25:08]~@[25:15] 이름 기반 소통을 고민하면 됨.
[^139]: @[25:15]~@[25:28] 템플릿이 한눈에 들어오게 관리 필요.
[^140]: @[25:29]~@[25:53] 템플릿 목록/디스크립션으로 안내 가능 설명.
[^141]: @[25:53]~@[26:07] 샘플 템플릿 제공 언급.
[^142]: @[26:07]~@[26:12] Well-Architected 환경 구성 필요.
[^143]: @[26:13]~@[26:17] 오픈소스 특성 필요 주장.
[^144]: @[26:17]~@[26:28] 템플릿 공유/직접 만들어보기.
[^145]: @[26:28]~@[26:34] 공유 템플릿 참조 후 변형 사용.
[^146]: @[26:44]~@[27:03] 공식 샘플 템플릿, 퍼블릭 프리뷰라 양 적음.
[^147]: @[27:03]~@[27:21] 템플릿 변경 가능→버전관리 필요.
[^148]: @[27:21]~@[27:31] 메이저/마이너 버전 관리 분리.
[^149]: @[27:31]~@[27:58] 마이너=투명 업데이트(인지 못한 사이 진행).
[^150]: @[28:04]~@[28:21] 메이저=선택지 제공, 최신버전 사용/버전업 필요 공지.
[^151]: @[28:25]~@[28:34] 개발자 관점에서 서비스 템플릿 선택 중요.
[^152]: @[28:34]~@[28:41] 선택만 가능해도 퍼포먼스 성장.
[^153]: @[28:49]~@[28:53] 현재는 Fargate 웹/Lambda로 제한.
[^154]: @[28:53]~@[29:05] 성장 시 다양한 템플릿 가능성.
[^155]: @[29:06]~@[29:16] 깊은 인프라 이해 대신…
[^156]: @[29:16]~@[29:23] 서비스 특성 이해 후 템플릿 선택.
[^157]: @[29:31]~@[29:35] 인프라 엔지니어의 템플릿+명세/도큐먼트.
[^158]: @[29:44]~@[29:50] 고려사항 공유.
[^159]: @[29:50]~@[30:09] 템플릿=교육자료, 개발자 성장 도움.
[^160]: @[30:14]~@[30:33] 서비스에서 사용 템플릿 확인→선택 배포.
[^161]: @[30:38]~@[30:48] 파라미터 입력 필요.
[^162]: @[30:54]~@[31:07] 캐시 크기/Route53 주소 등 예시.
[^163]: @[31:07]~@[31:19] 표준화: 입력 선택지 설계.
[^164]: @[31:19]~@[31:30] 필수 vs 옵션 파라미터.
[^165]: @[31:33]~@[31:42] 향후 코드로 배포 고도화 전망.
[^166]: @[31:42]~@[31:55] 파라미터만 입력해 빠른 배포 가능.
[^167]: @[31:56]~@[32:10] Dockerfile/브랜치 선택 등, 개발자는 코드 집중.
[^168]: @[32:22]~@[32:44] 서비스 관리/대시보드 필요.
[^169]: @[32:44]~@[32:56] 간략 대시보드 존재, CloudWatch 연계/고도화 전망.
[^170]: @[33:01]~@[33:15] 배포 실패/진행/성공, 성공 시점 확인.
[^171]: @[33:21]~@[33:29] 서비스 모니터링(헬스 모니터링) 필요.
[^172]: @[33:29]~@[33:58] 문제 지점/진행 상태/시도 횟수 등 제공 설명.
[^173]: @[33:58]~@[34:15] 화면은 팀마다 다를 수 있으나 대시보드 개념은 모범사례.
[^174]: @[34:21]~@[34:30] 퍼블릭 프리뷰, 출시 얼마 안 됨.
[^175]: @[34:30]~@[34:43] CloudFormation 기반 템플릿 작성/배포 제공.
[^176]: @[34:43]~@[35:00] CodePipeline 연계 CI/CD, 메이저/마이너 업그레이드 제공.
[^177]: @[35:00]~@[35:09] 로드맵 공개.
[^178]: @[35:09]~@[35:18] 헬스 모니터링 고도화, CloudWatch 통합.
[^179]: @[35:20]~@[35:36] CloudWatch 통합→Lambda 액션 붙여 코드 실행 가능.
[^180]: @[35:37]~@[35:53] Terraform 연계 계획 언급.
[^181]: @[35:53]~@[36:00] 사용자 템플릿 가공 지원 예정.
[^182]: @[36:00]~@[36:09] 템플릿 레벨 자동 태깅.
[^183]: @[36:09]~@[36:23] 값 하나로 자원 태그 일괄/네이밍류 맞춤.
[^184]: @[36:30]~@[36:43] 멀티 어카운트는 모범사례로 필수.
[^185]: @[36:43]~@[36:51] 개발/프로덕션 계정 분리는 당연.
[^186]: @[36:51]~@[37:01] Organizations 등과 연계 또는 다른 방식으로 멀티 어카운트 지원.
[^187]: @[37:01]~@[37:18] 팀별 템플릿 접근 필요.
[^188]: @[37:18]~@[37:25] IAM 통합 접근제어 제공 전망.
[^189]: @[37:30]~@[37:43] 지속 업데이트, 고객 피드백.
[^190]: @[37:43]~@[38:01] 신속/신뢰 가능한 컨테이너·서버리스 배포 모범사례 적용 비전.
[^191]: @[38:03]~@[38:13] 현대적 클라우드 아키텍처 쉽게(마이크로서비스).
[^192]: @[38:18]~@[38:24] 인프라팀이 비즈니스 성공 위한 아키텍처에 집중.
[^193]: @[38:13]~@[38:18] 마이크로서비스는 쉬운 문제가 아님.
[^194]: @[38:31]~@[38:37] IaC 실천으로 모범사례 빠르게 작성/공유.
[^195]: @[38:37]~@[38:49] 레포지토리/CI 연계.
[^196]: @[38:49]~@[38:56] 컨테이너/서버리스 접목, 마이크로서비스 손쉽게.
[^197]: @[39:05]~@[39:22] 개발팀이 일부 생성→의사소통/인프라팀 업무 감소→다른 일 가능.
[^198]: @[39:26]~@[39:38] 가속도 곡선 재언급, “어느 그래프 위?” 질문.
[^199]: @[39:38]~@[40:12] Proton 사용 고려 + 기존 배포와 비교/검토로 현재 위치 점검.
[^200]: @[40:12]~@[40:22] 빨간 그래프에 더 다가감.
[^201]: @[40:22]~@[40:42] 인프라팀이 데브옵스팀으로 진화: 퍼포먼스에 영향 주는 모든 일.
[^202]: @[40:47]~@[40:59] 기획/마케팅/운영 문제에도 자동화 영역.
[^203]: @[40:59]~@[41:21] 비전공/비개발 인력에게 CI 연계는 어렵다.
[^204]: @[41:23]~@[41:46] 데브옵스팀이 표준화/자동화로 디지털 트랜스포메이션.
[^205]: @[41:51]~@[42:11] 아키텍처/팀/수준 고민해 퍼포먼스·속도를 곡선 위로.
[^206]: @[00:35]~@[42:11] 전체 논지(정의→복잡성→표준화→Proton→조직 진화)에서 도출.
[^207]: @[00:35]~@[37:25] 용어가 실제로 등장하며 의미가 문맥에서 정의됨.
[^208]: 사용자 제공 메타데이터(제목/채널/길이/링크) 및 영상 정보.